home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-iplpdn-para-negotiation-01.txt < prev    next >
Text File  |  1993-07-08  |  14KB  |  437 lines
  1.  
  2.  
  3.  
  4.  
  5. Draft               Parameter Negotiation          July 1993
  6.  
  7.  
  8. INTERNET DRAFT
  9. Expires: January 7, 1994
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.                    Parameter Negotiation
  18.                           for the
  19.                  Multiprotocol Interconnect
  20.  
  21.  
  22. Keith Sklower
  23. Computer Science Department
  24. University of California, Berkeley
  25.  
  26. Clifford Frost
  27. Information Systems & Technology
  28. University of California, Berkeley
  29.  
  30. 1.   Status  of  This  Memo    This  document is an Internet
  31. Draft.  Internet Drafts are working documents of the  Inter-
  32. net  Engineering Task Force (IETF), its Areas, and its Work-
  33. ing Groups.  Note that  other  groups  may  also  distribute
  34. working documents as Internet Drafts.
  35.  
  36. Internet  Drafts  are draft documents valid for a maximum of
  37. six months.  Internet Drafts may be  updated,  replaced,  or
  38. obsoleted  by other documents at any time.  It is not appro-
  39. priate to use Internet Drafts as reference  material  or  to
  40. cite  them  other  than  as a ``working draft'' or ``work in
  41. progress.''
  42.  
  43. Please check the 1id-abstracts.txt listing contained in  the
  44. internet-drafts    Shadow    Directories   on   nic.ddn.mil,
  45. nnsc.nsf.net,    nic.nordu.net,     ftp.nisc.sri.com,     or
  46. munnari.oz.au  to  learn  the current status of any Internet
  47. Draft.
  48.  
  49. 2.  Abstract
  50.  
  51. This document describes mechanisms  for  negotiating  opera-
  52. tional  parameters  wherever  SNAP encapsulation of Internet
  53. Protocols is available.  For example, it is suitable for use
  54. in  conjunction  with  RFC  1294  (Multiprotocol  Over Frame
  55. Relay) and RFC 1356 (Multiprotocol Interconnect on X.25  and
  56. ISDN in the Packet Mode) [1,2], and potentially others.  The
  57. mechanisms described here are intended  as  optional  exten-
  58. sions,  intended to facilitate interoperation in public net-
  59. works were preconfiguration may not have been done symmetri-
  60. cally by all parties who wish to exchange information.
  61.  
  62.  
  63. Sklower & Frost                             [Page 1]
  64.  
  65.  
  66.  
  67. Draft               Parameter Negotiation          July 1993
  68.  
  69.  
  70. 3.  Acknowledgements
  71.  
  72. The  authors wish to thank Brian Lloyd of Lloyd & Associates
  73. and Bill Simpson of Daydreamer, Inc. for  extensive  discus-
  74. sion of the PPP protocol, Brad Steinke of Microcom, and Joel
  75. Halpern of Network Systems for useful suggestions, and espe-
  76. cially  Chris Ranch of Novell for details about the protocol
  77. itself.
  78.  
  79. 4.  Conventions
  80.  
  81. The following language conventions are used in the items  of
  82. specification in this document:
  83.  
  84. o    Must,  Shall  or  Mandatory  -- the item is an absolute
  85.      requirement of the specification.
  86.  
  87. o    Should or Recommended -- the item should  generally  be
  88.      followed for all but exceptional circumstances.
  89.  
  90. o    May  or  Optional -- the item is truly optional and may
  91.      be followed or ignored according to the  needs  of  the
  92.      implementor.
  93.  
  94. 5.  Introduction
  95.  
  96. When parties wish to exchange information over a public data
  97. network, it may be useful to perform sanity checks, such  as
  98. verifying  that  buffer sizes are sufficient to receive data
  99. being transmitted, or that there is agreement  as  to  which
  100. protocols  will  be  routed or bridged.  As another example,
  101. there may be circumstance in which the identity of a calling
  102. party  may  not  be  readily  available;  thus  some form of
  103. authentication may be desired.
  104.  
  105. The Point-to-Point Protocol (RFC 1331 and 1332)  provides  a
  106. means  of  achieving  these goals [3,4].  It is very general
  107. and can be adapted to any situation where there is a virtual
  108. point-to-point   connection   between   parties  wishing  to
  109. exchange information.  Both  RFC's  1294  and  1331  specify
  110. details  of  framing and encapsulation in incompatible ways;
  111. however, one can accommodate PPP's encapsulation of  control
  112. packets by prepending a SNAP header without otherwise chang-
  113. ing the description of the packets.
  114.  
  115. Alternatively, should ISO or CCITT be persuaded to grant  an
  116. NLPID  (identifier for use in ISO TR 9577[6]), the PPP pack-
  117. ets and encapsulations could co-exist  as  an  extension  to
  118. RFC's 1294 and 1356.
  119.  
  120. Members of the IPLPDN group expressed the desire that param-
  121. eter negotiation as a  whole  be  made  optional,  and  also
  122. wanted  to  be  able  to  renegotiate parameters at any time
  123.  
  124.  
  125. Sklower & Frost                             [Page 2]
  126.  
  127.  
  128.  
  129. Draft               Parameter Negotiation          July 1993
  130.  
  131.  
  132. during the course of an association.  Both  of  these  goals
  133. can be met without violating the current PPP spec.
  134.  
  135. 6.  Frame Format
  136.  
  137. 6.1.  Basic Format
  138.  
  139. In  this  document,  we  propose prepending a SNAP header to
  140. otherwise unchanged PPP (data and control) packets [5].  The
  141. SNAP  header MUST specify an OUI of 0 (Xerox Ethernet Encap-
  142. sulation).  The protocol ID field MUST be 0x0B03.  A  system
  143. SHOULD  recognize  incoming  PPP data packets.  We RECOMMEND
  144. that only control or negotiation type PPP packets be  trans-
  145. mitted  in  this  fashion,  since RFCs 1294 and 1356 already
  146. specify a means of encapsulating data packets.
  147.  
  148. Since we are proposing using this in conjunction  with  both
  149. RFC1294  and RFC1356, we give an example in each packet for-
  150. mat:
  151.  
  152.  
  153.      Sample Frame Relay PPP LCP packet
  154.          +-----------------------------+
  155.          |    flag (7E hexadecimal)    |
  156.          +-----------------------------+
  157.          |       Q.922 Address         |
  158.          +--                         --+
  159.          |                             |
  160.          +-----------------------------+
  161.          | Control (UI = 0x03)         |
  162.          +-----------------------------+
  163.          | Optional Pad(s)   (0x00)    |
  164.          +-----------------------------+
  165.          | NLPID              0x80     |
  166.          +-----------------------------+
  167.          | OUI                0x00     |
  168.          +--           .             --+
  169.          | OUI                0x00     |
  170.          +--           .             --+
  171.          | OUI                0x00     |
  172.          |     (three octets)          |
  173.          +-----------------------------+
  174.          | ETHERTYPE          0x0B     |
  175.          +--           .             --+
  176.          | ETHERTYPE          0x03     |
  177.          |       (two octets)          |
  178.          +-----------------------------+
  179.          | PPP  Protocol (e.g. 0x0c)   |
  180.          +--           .             --+
  181.          | PPP  Protocol (0x21 for LCP)|
  182.          |       (two octets)          |
  183.          +-----------------------------+
  184.          |           Data              |
  185.  
  186.  
  187. Sklower & Frost                             [Page 3]
  188.  
  189.  
  190.  
  191. Draft               Parameter Negotiation          July 1993
  192.  
  193.  
  194.          |   (e.g   LCP  Code  )       |
  195.          +-----------------------------+
  196.          |   (e.g   LCP  Identifier)   |
  197.          +-----------------------------+
  198.          |   (e.g.  LCP  Option Length)|
  199.          +--           .             --+
  200.          |       (two octets)          |
  201.          +-----------------------------+
  202.          |   (e.g.  LCP  Option)       |
  203.          |             .               |
  204.          |             .               |
  205.          |             .               |
  206.          |             .               |
  207.          +-----------------------------+
  208.          |   Frame Check Sequence      |
  209.          +--           .             --+
  210.          |       (two octets)          |
  211.          +-----------------------------+
  212.          |   flag (7E hexadecimal)     |
  213.          +-----------------------------+
  214.  
  215.  
  216.         Sample X.25 PPP LCP packet
  217.          +-----------------------------+
  218.          |    flag (7E hexadecimal)    |
  219.          +-----------------------------+
  220.          | Address A or B   0x1 or 0x3 |
  221.          +--                         --+
  222.          |       LAPB Control          |
  223.          +-----------------------------+
  224.          |  D,Q bits | SVC# high order |
  225.          +-----------------------------+
  226.          |       SVC low order         |
  227.          +-----------------------------+
  228.          | p(r)   | m_bit | p(s)   | 0 |
  229.          +-----------------------------+
  230.          | NLPID              0x80     |
  231.          +-----------------------------+
  232.          | OUI                0x00     |
  233.          +--           .             --+
  234.          | OUI                0x00     |
  235.          +--           .             --+
  236.          | OUI                0x00     |
  237.          |     (three octets)          |
  238.          +-----------------------------+
  239.          | ETHERTYPE          0x0B     |
  240.          +--           .             --+
  241.          | ETHERTYPE          0x03     |
  242.          |       (two octets)          |
  243.          +-----------------------------+
  244.          | PPP  Protocol (e.g. 0x0c)   |
  245.          +--           .             --+
  246.          | PPP  Protocol (0x21 for LCP)|
  247.  
  248.  
  249. Sklower & Frost                             [Page 4]
  250.  
  251.  
  252.  
  253. Draft               Parameter Negotiation          July 1993
  254.  
  255.  
  256.          |       (two octets)          |
  257.          +-----------------------------+
  258.          |           Data              |
  259.          |   (e.g   LCP  Code  )       |
  260.          +-----------------------------+
  261.          |   (e.g   LCP  Identifier)   |
  262.          +-----------------------------+
  263.          |   (e.g.  LCP  Option Length)|
  264.          +--           .             --+
  265.          |       (two octets)          |
  266.          +-----------------------------+
  267.          |   (e.g.  LCP  Option)       |
  268.          |             .               |
  269.          |             .               |
  270.          |             .               |
  271.          |             .               |
  272.          +-----------------------------+
  273.          |   Frame Check Sequence      |
  274.          +--           .             --+
  275.          |       (two octets)          |
  276.          +-----------------------------+
  277.          |   flag (7E hexadecimal)     |
  278.          +-----------------------------+
  279.  
  280. Since one of the packet formats specified in RFC1356 permits
  281. logically  prepending  the  call user data supplied when the
  282. virtual circuit was established to each  packet  transmitted
  283. over  that  virtual  circuit,  one could transmit PPP packet
  284. unchanged if the 6 byte snap header is supplied as the  call
  285. user  data.   Equivalently,  if a NLPID for PPP is obtained,
  286. then the single byte NLPID is all that is required as CUD.
  287.  
  288. 6.2.  Supported Types
  289.  
  290. The PPP protocol is a rich language and allows many  options
  291. to  be negotiated.  An implementation MAY request any option
  292. specified by PPP, but MAY decline  to  support  any  option.
  293. Because  PPP and Frame Relay encapsulations evolved indepen-
  294. dently, there are duplicate  ways  to  obtain  configuration
  295. information  such  as the IP address of the other end of the
  296. PVC - by inverse arp, or determine the transmit and  receive
  297. buffer  sizes  -  by  XID negotiation.  Where there are such
  298. choices, it is RECOMMENDED that an implementation adhere  to
  299. practice specified in the Frame Relay and X.25 RFCs.  Manual
  300. configuration also implicitly provides information that  may
  301. otherwise have been explicitly negotiated.
  302.  
  303. 7.  Changes to PPP semantics
  304.  
  305. 7.1.  Optionality and Separability of Negotiations
  306.  
  307. As  noted  above, people have expressed the desire not to be
  308. required to conduct  any  negotiations  before  transmitting
  309.  
  310.  
  311. Sklower & Frost                             [Page 5]
  312.  
  313.  
  314.  
  315. Draft               Parameter Negotiation          July 1993
  316.  
  317.  
  318. data packets in a public data network environment.  Thus, an
  319. implementation MAY silently ignore any SNAP encapsulated PPP
  320. packet.   If  an  implementation responds to LCP packets, it
  321. MUST traverse the LCP state diagram according to RFC1331.
  322.  
  323. If an implementation responds to NCP packets for any partic-
  324. ular  protocol,  it MUST otherwise obey the rules of the RFC
  325. for that corresponding NCP.
  326.  
  327. One reason for making negotiations optional is  cost;  there
  328. are  environments  which  charge by the packet and there are
  329. applications such as mail hubs which generally exchange only
  330. a  few  data  packets with a given remote host and then will
  331. not exchange any other packets for relatively  long  periods
  332. of time.
  333.  
  334. Another  reason is simplicity of implementation.  For use of
  335. small computers at home, people may wish to be able to  only
  336. support  the  required  packet  framing.  Or, for routers at
  337. campus or business hubs, this could reduce  memory  require-
  338. ments from having to maintain state information for hundreds
  339. of virtual point-to-point connections.
  340.  
  341. Another reason is reduction of latency.
  342.  
  343. 8.  References
  344.  
  345. [1]  Bradley, T., Brown, C., and Malis,  A.,  "Multiprotocol
  346.      Interconnect  over Frame Relay", Network Working Group,
  347.      RFC-1294, January 1992.
  348.  
  349. [2]  Malis, A.,  Robinson,  D.,  Ullman  R.,  "Multiprotocol
  350.      Interconnect on X.25 and ISDN in the Packet Mode", Net-
  351.      work Working Group, RFC-1356, August 1992.
  352.  
  353. [3]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
  354.      Transmission of Multi-protocol Datagrams over Point-to-
  355.      Point Links",  Network  Working  Group,  RFC-1331,  May
  356.      1992.
  357.  
  358. [4]  McGregor, G., "The PPP Internet Protocol Control Proto-
  359.      col (IPCP)" Network Working Group, RFC-1332, May  1992.
  360.  
  361. [5]  Postel, J. and Reynolds, J., "A Standard for the Trans-
  362.      mission of IP Datagrams over IEEE 802  Networks",  ISI,
  363.      RFC-1042, February 1988.
  364.  
  365. [6]  International Organization for Standardization, "Infor-
  366.      mation technology - Telecommunications and Informations
  367.      exchange  between  systems - Protocol identification in
  368.      the network  layer",  Technical  Report  9577,  October
  369.      1990.
  370.  
  371.  
  372.  
  373. Sklower & Frost                             [Page 6]
  374.  
  375.  
  376.  
  377. Draft               Parameter Negotiation          July 1993
  378.  
  379.  
  380. 9.  Authors' Addresses
  381.  
  382. Keith Sklower
  383. Computer Science Department
  384. 570 Evans Hall
  385. University of California
  386. Berkeley, CA  94720
  387.  
  388. Phone:  (510) 642-9587
  389. E-mail:  sklower@cs.Berkeley.EDU
  390.  
  391.  
  392.  
  393. Clifford Frost
  394. Information Systems & Technology
  395. 275 Evans Hall
  396. University of California
  397. Berkeley, CA  94720
  398.  
  399. Phone:  (510) 642-5360
  400. E-mail:  cliff@cmsa.Berkeley.EDU
  401.  
  402. 10.  Expiration Date of this Draft
  403.  
  404. January 7, 1994
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435. Sklower & Frost                             [Page 7]
  436.  
  437.